The publish/subscribe communication paradigm describes a known form of interaction in distributed computing settings. In a publish/subscribe system, a subscriber may register interest in or subscribe to events pertaining to a given topic; thereafter, the subscriber receives notifications of such events, which are produced by publishers.
In a publish/subscribe system, publishers or senders of data do not communicate directly with subscribers or receivers; instead, publishers and subscribers interact through an intermediate entity referred to here as a channel, but also known in the art by various other names, such as notification server, broker or event service. Publishers may publish notifications about the occurrence of the events on a channel by first marking these notifications with a particular topic. Subscribers receive notifications in the form of the messages from the channel for events that conform to the topic(s) in which they have registered interest. Since message producers (publishers) and consumers (subscribers) communicate indirectly with each other via a channel, message transmission is decoupled from message reception. As a consequence, neither producers nor consumers need to maintain state about each other, and dependencies between the interacting participants are reduced or eliminated. The publish/subscribe scheme is therefore more flexible than other communication paradigms, such as point-to-point messaging, because publishers and subscribers can be started and stopped asynchronously.
The publish/subscribe mechanism is well suited to messaging systems in which many sensors monitor the dynamically changing state of some underlying system and forward measurement data to a central server site. The central server site, which receives the measurement data, typically employs an application server that processes the information, stores it in a database, and provides an interface to an application user. As processors become more and more inexpensive, and as advances are made in wireless communication, many simple sensors may be added to existing systems in order to enhance monitoring and management thereof. The sensors produce notifications about changes in state of the underlying system and therefore are modeled as publishers of particular types of events or topics. Sensors, in this context, are modeled as publishers of particular types of events or topics, and the systems that monitor the events are modeled as subscribers. Here, the term “event” refers to a change in state in the underlying system.
In a sensor network, sensors inform the application server about the occurrence of events through notification messages. Large, distributed systems may have many, many sensors, and the frequency at which they send notifications may be very high. For example, in an application that uses RFID tags to follow the movement of products in a supermarket, if every article pickup in every supermarket in a chain of stores is sent as a notification to the supermarket chain's back-end server, then the volume of notifications could rise to tens of thousands per second. Thus, an application server can become overloaded if every notification is delivered to it.
To reduce the load on the application server, an architectural entity may be placed between the sensors and the application server. This entity is termed an edge server, as it is logically located at the edge of the network. Edge servers pre-process raw sensor data and may aggregate information to enable certain sensor applications to be scalable. Thus, edge servers may intercept notifications, process them and send aggregations or summaries of the information they contain to the application server.
Edge servers subscribe to channels on a given topic and may publish messages to application code on a potentially different channel on the same or a different topic. An application server or edge server “wants” to receive only the most condensed or aggregated form of a notification from a sensor; that is, there is no advantage in receiving both the “raw” notification and a summary of the many raw notifications in which it is included.
An edge server based architecture nevertheless raises a number of technical challenges. For one thing, deploying large numbers of edge servers means that failures of parts of the system typically occur so frequently that failure is the norm rather than the exception. This problem is exacerbated by the fact that edge servers often execute in a more hostile and less well-protected environment than application servers, in the sense that edge servers are typically deployed out “in the field” and are not as easily protected as within large, centralized server farms. In such cases, the failure of an edge server that normally collects data from many publishers (such as sensors or other edge servers) is problematic: in the absence of a means for the publishers to learn that they should now publish messages elsewhere, the data will typically be lost.
Challenges are also posed by the communication requirements from sensors to edge servers, edge servers to edge servers, and edge servers to application server. Messages sent by sensors are typically transmitted over wireless links. The messaging system therefore needs to take into account the particularities of wireless communication, i.e., (i) that bandwidth is typically less abundant than in a fixed network; and (ii) that wireless communication is more subject to noise and interruption. Since a message generated by an edge server is typically the result of a pre-processing step, the information content is higher and consequently is more valuable than the messages produced by the sensors and must be better protected from loss. In addition, the application server typically employs a messaging system that is rich with functionality and follows certain standards. As a consequence, several different messaging systems with potentially a large number of independent channels are required if edge servers are to be deployed in a large, distributed sensor network.
A further challenge posed by known messaging systems is that the administration of the entire system becomes more complex with an edge server-based architecture. If a large number of edge servers are deployed, it is extremely difficult to configure each of them manually, so that all entities know to which channels they should subscribe and to which they should publish. Known systems are also difficult to reconfigure as loads change, or as edge servers or channels are stopped and started.
The Applicant therefore believes that there is a need for more resilient and scalable tracking of notifications in publish/subscribe systems.